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$0/ Claims 1-16 are all the claims pending in the application. Claims 1-13 are rejected. 
Claims 14-16 are allowed. 

As a preliminary matter, Applicants and their representatives wish to thank Examiner Lee 
and SPE Kizou for the courtesy extended during a personal interview conducted on January 22, 
2004. Applicants believe that a further mutual understanding of the invention and the 
distinctions over the prior art was reached. Applicants now submit that all of the claims should 
be allowed for the following reasons. 

Claim Rejections - 35 U.S.C. § 103 
Claims 1-13 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Luczycki et al (6,523,069) in view of Donahue et al (6,101,180). The Examiner looks to the 
newly cited patent to Luczycki et al for a teaching in Fig. 6 of a plurality of routers 60A-60N, 
each associated with a plurality of requesting terminals. The Examiner asserts that the multicast 
source 54 is a "route server," as claimed, in that it is in communication with a plurality of routers 
to establish a multicast tree . This rejection is traversed for at least the following reasons. 

The Present Invention 

As previously explained in earlier amendments, the present invention concerns the 
provision of internet protocol (IP) multicast services on mesh satellite networks, of the type 
illustrated in Fig. 1 of the application. In particular, the invention is focused on avoiding the 
incorporation in each terminal of the needed support for multicast IP routing in a mesh satellite 
network. The invention avoids the need for each terminal having a router to periodically 
communicate with all the terminal/routers in the mesh, thereby using satellite bandwidth, as well 
as significant CPU and memory resources. 

The present invention uses a centralized route server to run the multicast routing 
protocols, thereby avoiding the need to use bandwidth for routing multicast IP traffic over 
meshed satellite networks. While Fig. 1 illustrates a connection of satellite TDMA terminals 
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through multicast enabled routers, as in Luczycki et al, the communication of routing 
information is significantly different. External routers establish multicast routing sessions only 
with a route-server , and not with the other terminals. Thus, multicast routing packets (not 
communication packets) originated by an external router attached to a terminal will be conveyed 
transparently to the common route server . The route server creates and stores multicast group 
table information for all routers. The single route server then provides that information to the 
terminals so that multicast traffic can be directly transmitted from the ingress terminal to all the 
terminals in a group, without having to be relayed through the route server . 

As illustrated in Fig. 1, the route server 40 is disposed at a master terminal 32 and is 
connected to a network control center 30, which communicates with the satellite 12 via the 
master terminal. Other terminals 16, 34; 18, 36 at separate ISPs are connected to various routers 
(52, 54, 58) for access to external equipment. As illustrated in Fig. 2, a master routing table is 
established in the RS 40 by communication among the RS and other routers 52, 54, 56, 58. 

Unlike the prior art arrangement of Fig. 3, the invention permits a reduction in the 
number of slots required for routing information updates, as illustrated in Fig. 4. This reduction 
occurs because the routing information is exchanged only between each router and the route 
server 40, and not among all routers . This fundamental feature of the present invention is recited 
in the rejected claims, particularly claim 1. 

In claim 1, the system has a plurality of terminals for providing IP multicast services as 
well as (1) a route server for establishing and maintaining routing information for a plurality of 
routers and (2) a controller operative to allocate broadcast burst to the terminals based on 
requests from the terminals via said route server . The requirement for the allocation of broadcast 
bursts based on requests from terminals "via said route server" is significant because it 
emphasizes the distinctive feature of the invention that information for such transmissions is 
exchanged only between external routers and the route server , and not among the external routers 
directly, as disclosed at page 7 of the present application. 
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Prior Art 

In the Examiner's analysis supporting his rejection of claims 1-13, the Examiner looks to 
Luczycki et al, particularly Fig. 6, for an illustration of a plurality of terminals each connected to 
a router, and a route server. The flaw in this part of the Examiner's analysis is that there is no 
"route server" in Luczycki et al. All of the routers will exchange routing information in the same 
manner as in the conventional art. 

The Examiner looks to the multicast source 54 as the route server. However, this is 
simply a source of traffic, and not of route information for distribution to all routers in the 
network. As explained at col. 5, lines 22-24, the "requested data stream is sent form the source 
54 to the destination terminal 56A through the gateways in the multicast tree. There is no 
teaching or suggestion that the source 54 acts as a route server. 

Indeed, the text at col. 5, lines 3-18 indicates that the multicast group, comprising virtual 
destination network address, is actively received and/or distributed by one of more multicast- 
enabled gateways, such as routers or switches, based on user requests. This is a teaching of the 
conventional distribution of route information in the network to setup the tree, from router to 
router, and not via a common server. 

The Examiner admits that the Luczycki et al reference does not have a "controller" as 
claimed, i.e., operative to allocate broadcast bursts to terminals based on requests from the 
terminals via the route server. The Examiner's own admission shows that a route server cannot 
be found in Luczycki et al because, if there were one, the controller would necessarily have been 
disclosed as well, since the controller and route server 

The Examiner looks to Donohue et al for a teaching of a file server coupled to a satellite 
for IP multicasting bursts of requested information to a plurality of local access points. The 
Examiner asserts that this teaching would lead one skilled in the art to use such file server in 
Luczycki et al. However, this begs the question as to whether the use of a route server is 
considered by any prior art reference. Clearly, neither Luczycki et al nor Donohue et al teach a 
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route server. Luczycki et al is admitted not to teach a controller, as claimed. Donohue et al, in a 
similar way, cannot and does not teach a controller that would support a route server, as claimed. 

As to the dependent claims 2-13, the Examiner's analysis does not remedy the basic 
defect in the teachings of the two main prior art references. 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 

The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 



Respectfully submitted, 



SUGHRUE MION, PLLC 

2100 Pennsylvania Avenue, N.W. 

Washington, D.C. 20037-3213 




Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 
Date: January 23, 2004 



